1. Field of the Invention
The present invention generally relates to computer systems and more particularly to input/output (I/O) processing within computer systems.
2. Description of the Related Art
Computer systems typically include one or more central processing units (CPUs) and memory, collectively referred to as a processing complex, and an I/O interface to allow the processing complex to communicate with peripheral or external I/O devices. The I/O interface is generally designed to facilitate communication between the processing complex and a wide variety of I/O devices, such as hard disks, network adapters, and the like.
One type of I/O interface utilized by some computer systems is a hierarchical input/output (I/O) interface, in which a variety of I/O devices are interfaced with the processing complex through a hierarchical arrangement of I/O adapters (IOAs) and input/output processors (IOPs). An IOA generally refers to interface control logic for a peripheral component that implements a particular type of connection (e.g., Ethernet, SCSI, and the like). As such, IOAs are typically fairly simple, and often lack powerful processors and large arrays of memory. An IOP, on the other hand, generally refers to interface control logic that typically includes a relatively complex processor and an appreciable amount of memory, and is often used as an interface between the processor complex and several other IOAs. An IOP may be considered a specific, powerful example of an IOA.
A single IOP may handle much of the I/O processing for several IOAs that might otherwise be handled by the processor complex. By allocating I/O processing to an IOP, significant performance gains are often realized, since the processing complex can be freed from having to directly handle many of the (often time-consuming) operations associated with I/O data transfers and interrupt handling associated with the IOAs. Moreover, IOPs typically provide a highly configurable and flexible interface for peripheral components, since much of the interface logic can be implemented in software that is executed by the IOPs. As a result, IOPs may hide many of the details specific to the underlying hardware of the peripheral components from the processor complex.
In conventional I/O protocols, operating system device driver programs create command messages that are transmitted across an I/O bus to a targeted IOP. The IOP interprets the command and performs the requested operation, usually transferring data between an I/O device connected to the IOP and main memory across the I/O bus. Data is typically transferred by using known direct memory access (DMA) mechanisms that are part of the I/O bus functions. In some implementations, when the IOP completes the requested operation, it creates a response message that is also DMA'd to main memory. The response message may then be retrieved from response queue by a CPU for interpretation by a device driver or application program running on the operating system.
One particular I/O bus implementation uses a pair of message queues to communicate with IOPs. The pair of message queues consists of a “downstream” message queue for sending (command) messages to the IOP, and an “upstream” queue for receiving (response) messages from the IOP. Both are circular queues that may reside in main memory. IOP hardware typically uses DMA to access the downstream queue to retrieve downstream messages and to access the upstream queue to enqueue (place in the upstream queue) upstream messages.
Typically, the IOP hardware that supports the queueing includes an interrupt mechanism that also allows for the creation of interrupts to signal the operating system upon the occurrence of various events relating to the message queues. For example, the IOP hardware may generate an interrupt when a particular downstream message has been retrieved, when the downstream queue is full (e.g., the operating system had enqueued messages in all available queue entry locations), and when a downstream queue full condition has been relieved (e.g., IOP has emptied a number of queue entry locations after the queue had become full). The IOP may also generate an interrupt when one or more upstream messages has been posted to the upstream queue.
In response to receiving one of these interrupts, a CPU of the processor complex may switch processor execution from its current program to an operating system or device driver program designed to interpret and process (handle) the interrupt event. While this interrupt mechanism can minimize the latency associated with the completion of an I/O command and interpretation of a response message, switching the processor execution from its current program to an interrupt program requires a processor context switch that may require many instruction cycles. For example, a context switch may involve saving a currently executing task's critical information (such as selected processor registers and state information) and loading an interrupt handler's critical information. Further, when the interrupt handler completes its processing, there is another context switch to restore the critical information of the interrupted task to resume its execution.
Thus, IOP interrupts can be disruptive to the system and may decrease performance. Accordingly, there is a need for an improved method and system for communicating between a processor complex and an IOP, preferably that decrease the disruptive effects of IOP interrupts.